askBettingAmount()에서 입력을 처음에는 String으로 받아 문자열 검증 후 int로 변환하는 방향을 생각했습니다.
다만 Scanner.nextInt()를 사용하면 숫자가 아닌 입력에 대해 기본적인 검증 효과를 바로 얻을 수 있어서,
구현 복잡도를 줄이기 위해 현재는 nextInt()를 사용하는 방식으로 변경했습니다.

이 경우 입력 계층에서 별도의 문자열 검증 로직을 두지 않아도 된다는 장점이 있다고 봤는데,
이런 상황에서 String -> 검증 -> 변환 흐름을 유지하는 편이 더 낫다고 보시는지,
아니면 nextInt()를 활용해 입력 단계의 복잡도를 줄이는 방향도 괜찮다고 보시는지 의견이 궁금합니다.

nextInt를 사용하고 숫자가 아닌 문자를 입력했을때
어떤 에러메세지가 보이던가요??
사용자가 쉽게 이해하기 좋은 메세지가 내려오는지를 판단해보면 좋을것 같습니다

exception 의 메세지를 테스트로 하는것은 좋은 방법은 아닐것 같아요, 에러메세지는 자주 바뀔수 있고 값이 추가되는등 변경사항이 잦은 부분일것 같습니다!

리뷰 주신 내용을 반영해 현재는 예외 메시지 비교 대신 예외 타입만 검증하도록 테스트를 리팩터링했습니다.

다만 이렇게 변경하고 보니, IllegalArgumentException만으로는 "예외가 발생했다"는 사실은 확인할 수 있지만,
정말 의도한 상황에서 적절한 예외가 발생했는지까지는 충분히 드러나지 않는다는 고민이 들었습니다.

이런 경우를 구분하기 위해 보통 커스텀 예외를 도입하게 되는지 궁금합니다.
즉, 메시지 자체를 테스트에 고정하지 않으면서도 예외의 의미를 더 명확하게 검증하려면
커스텀 예외로 책임을 분리하는 방식이 일반적인지 의견을 듣고 싶습니다.

커스텀 예외는 정말 특수한 예외인경우에 대해서만 만드는 편인것 같아요.
프론트에서 별도로 Exception 타입을 보고 처리가 필요한 경우요

실제 대부부의 회사들은 그냥 input으로 잘못들어온건 프론트에서 별다른 처리 없이(여기서는 view) 사용자에게 메세지만 잘 전달되면 되기 때문에 하나의 에러로 간주해서 처리할것 같습니다!

입력 검증 책임을 InputView에서 분리해 InputValidator를 만들고, 해당 검증 로직을 별도로 테스트하도록 변경했습니다.

리뷰에서 InputStream을 직접 바꿔가며 테스트하는 방식은 권장하지 않는다고 말씀해주셨는데,
그 이유가 System.setIn()이 JVM 전역 상태를 변경하기 때문인지 궁금합니다.

제가 이해한 바로는, 이런 방식은 테스트 수가 많아졌을 때 전체 테스트 실행 과정에서 다른 테스트와 상태를 공유하게 되고,
특히 병렬 실행 환경에서는 예기치 않은 실패나 race condition 같은 문제로 이어질 수 있을 것 같습니다.

즉, InputStream 기반 테스트를 지양하는 주된 이유가
전역 상태 변경으로 인해 테스트 격리가 깨지고, 실행 순서나 동시성에 영향을 받을 수 있기 때문인지 확인받고 싶습니다.

흠 저도 깊게 고민해보지 못한 포인트네요
제 관점에서는 view는 사실 프론트의 영역이고 백엔드는 도메인 테스트에 집중하자가 포인트였습니다.
보통은 System.setIn() 과 같은 코드까지 짜면서 테스트를 하는 케이스를 본적이 없어서 익숙하지 않음에 리뷰 드렸습니다.

위와 같은 문제도 충분히 발생할수 있을것 같네요! 학습하신 내용으로도 충분히 이런 테스트는 하지 않는 방향이 좋을것 같습니다!

Players를 일급 컬렉션으로 도입한 뒤, 내부 컬렉션 표현을 외부에 노출하지 않기 위해 forEach 메서드를 추가했습니다.
(getPlayers를 쓰면 캡슐화가 약해진다. 바깥에서 내부구현 List에 의존하게 된다.)
이 과정에서 리팩터링 방향을 잡거나 익숙하지 않은 문법을 적용할 때 AI 도움을 일부 받았습니다.

예를 들어 forEach 메서드 사용해서 리팩토링 해줘! 이런식으로
구조를 바꾸는 과정에서 AI에게 구현 방향이나 스켈레톤 코드 예시를 요청하는 방식으로 사용했습니다.

이럴 때 AI를 활용하는 것이 학습에 실제로 도움이 되는 방식인지,
아니면 익숙하지 않은 문법이나 리팩터링은 직접 더 많이 손으로 써보는 쪽이 낫다고 보시는지 궁금합니다.

특히 이런 경우,
"AI에게 바로 구현을 맡기는 것"과
"AI에게 방향/힌트만 받고 직접 구현하는 것"
사이에서 어떤 방식으로 활용하는 것이 학습에 더 도움이 되는지도 의견을 듣고 싶습니다.
익숙하지 않은 문법은 어떤 식으로 학습을 해야할까요?

forEach를 이렇게 쓰는것보다 상황에 맞는 메서드를 직접 구현하는게 좋다고 생각하빈다.
consumer를 통해서 어떤값이 들어올지 모르고 외부에서 players에 대해서 아무값이나 변경이 가능할것 같아서요.

학습을 하는데 있어서는 AI에게 바로 구현을 하기보다는 먼저 구현을 해보고 AI와 토론을 해보는게 좋을것 같습니다.
예전에는 익숙하지 않은 언어나 기능들을 학습하기 위해서는 Test 코드를 통해 이것저것 연습해보고 했었는데
지금은 AI를 이용하여 어떻게 학습할수 있을지 고민해보면 좋을것 같습니다. 이런 질문들도 AI에게 한번 물어보세요!

Cards 라는 클래스가 Deck에도 쓰이고 Participant에도 쓰이고 있는것 같아요
현실에서는 같은 카드들일지라도 객체의 관점에서는 deck의 cards와 participant의 cards는 다를것 같아요 deck은 카드를 draw하는 역할이고 participant의 카드들은 추가하고 점수를 계산하는 역할이 있을것 같은데요 이 경우에 어떻게 일급컬렉션을 활용할 수 있을지 고민해보면 좋을것 같아요 다음 사이클 진행을 위해 제 생각을 먼저 공유하자면 Deck 자체로 List 를 감싸고 있는 일급컬렉션이라고 생각합니다 Deck의 필드로는 List 가 있어야하고 participant가 가지고 있는게 Cards 가 되어야하지 않을까 싶습니다.

리뷰 주신 방향을 반영해 구조를 다시 고민해봤습니다.

처음에는 Card를 단일 카드 1장, Cards를 Card의 복수형, Deck을 52장의 카드와 셔플/드로우 규칙을 가진 Cards의 특수한 상황으로 생각했습니다. 그래서 Cards를 먼저 일급 컬렉션으로 두고, 이를 Deck과 ParticipantCards가 내부적으로 사용하는 구조를 생각했습니다.

다만 구현 과정에서 에이스 점수 계산을 위해 changeAvailableAceCount 같은 상태가 들어가면서,
기존 Cards가 순수한 컬렉션이라기보다 사실상 참가자 카드 책임까지 함께 가지는 형태가 되었다고 느꼈습니다.
그래서 이후에는 Cards는 순수하게 카드 리스트를 감싸는 역할로 두고,
참가자의 카드 관리와 점수 계산 책임은 ParticipantCards로 분리하는 방향으로 정리해봤습니다.

이렇게 바꾸고 보니 Cards와 ParticipantCards의 책임이 이전보다 어느 정도 분리된다고 느꼈습니다.
다만 여전히 고민되는 부분은,
리뷰에서 말씀해주신 것처럼 Deck 자체가 카드 리스트를 직접 가진 일급 컬렉션이 되고,
참가자는 별도의 Cards 또는 ParticipantCards를 가지는 구조가 더 자연스러운지입니다.

즉 현재 제가 적용한 방향과,
리뷰에서 제안해주신 "Deck과 Participant 쪽 컬렉션 책임을 더 명확히 분리하는 방향" 중에서
어느 쪽이 더 객체지향적으로 자연스럽고 확장에 유리한지 의견을 듣고 싶습니다.

추가로, 초기에 ParticipantCards에 getSize() 같은 메서드도 두었다가 사용하지 않아 제거했는데,
이런 메서드들은 현재 필요가 없더라도 이후 확장 가능성을 보고 남겨두는 편이 좋은지,
아니면 실제 사용 시점에 추가하는 편이 더 나은지도 궁금합니다.

ParticipantCards, Deck 각각이 List 를 필드로 가진 일급컬렉션 각각 클래스가 되어야할것 같습니다.
Cards라는 클래스는 현재 구조에서 필요없을것 같아요
객체 클래스의 depth만 깊어져서 오히려 복잡성이 증가하고 있는 구조인것 같습니다

에이스 점수 계산을 위해서 changeAvailableAceAcount가 있는구조가 좋은 방향인지도 고민해보면 좋을것 같아요
점수 계산을 할때 ace 여부를 체크하면 되지 않을까요?

안녕하세요!
Cards를 별도 일급 컬렉션으로 둔 이유는, Deck과 ParticipantCards가 모두 카드 리스트를 다루고 있기 때문에
장기적으로 공통 컬렉션 추상화가 있으면 확장에 유리할 수 있다고 판단했기 때문입니다.

다만 리뷰를 보면서,
현재 구조에서는 이런 공통 추상화가 확장성을 높이기보다 오히려 depth만 늘리고
불필요한 추상화가 될 수 있다는 관점도 이해하게 되었습니다.

그래서 이 부분에 대해 한 가지 더 여쭤보고 싶습니다.

저는 "미래에 공통 로직이 늘어날 가능성"을 보고 Cards를 유지하려 했는데,
영이는 현재 시점에서는 Deck과 ParticipantCards의 책임이 이미 다르기 때문에
굳이 같은 컬렉션 추상화로 묶지 않는 편이 더 자연스럽다고 보신 것 같았습니다.

혹시 이런 경우에 공통 추상화를 남길지, 각 도메인이 직접 리스트를 가지게 할지 어떤 기준으로 판단하시는지 궁금합니다.

예를 들어

• 단순히 내부적으로 같은 List<Card>를 가진다는 사실만으로는 부족한지
• 실제로 공유하는 책임/행위가 충분히 안정적일 때만 추상화를 남겨야 하는지
• 혹은 현재 요구사항에서 직접 쓰이지 않는 확장성은 일단 접어두고, 필요해졌을 때 추출하는 편을 선호하시는지

같은 판단 기준이 궁금합니다.

추후에는 말씀해주신 방향으로도 직접 리팩터링해보면서 구조를 비교해볼 생각입니다.

Cards 라는 클래스에서 추후 공통로직으로 쓰일만한게 어떤게 있나요??
제가 생각했을때 지금 Cards 의 메서드들은 공통적인 기능이라기보다 List 에서 기본적으로 제공되는 기능들을 한번더 호출하는 역할 밖에 없는것 같아요
추후 공통적인 기능이 생긴다는 영역도 List 에서 제공되는걸 한번더 메서드 depth만 늘릴것 같다고 생각합니다!

스트림을 사용하는 방향에 대해서도 의견을 듣고 싶습니다.

리팩터링 과정에서 일부 컬렉션 순회 로직을 스트림으로 바꿔볼 수 있겠다고 느낀 부분이 있었는데,
개인적으로는 아직 for문이나 forEach 기반 순회가 더 직관적으로 읽히는 경우가 많다고 느꼈습니다.

그래서 모든 순회 로직을 스트림으로 바꾸는 것이 꼭 더 좋은 방향인지,
아니면 가독성과 의도가 더 잘 드러나는 경우에는 일반 반복문을 유지하는 것도 괜찮은지 궁금합니다.

또 실제 현업에서는 컬렉션 처리 시 스트림을 기본적으로 많이 사용하는 편인지,
아니면 팀/상황에 따라 반복문과 스트림을 구분해서 사용하는지도 함께 여쭤보고 싶습니다.

상황에 따라 더 가독성, 성능 등을 잘 고려해서 판단하시는게 좋을것 같습니다!
모든 상황에서 스트림이 좋다고 forEach, for문이 좋다고 할수는 없을것 같아요
딱 정의해서 말할수 없는것 같고 개발을 진행하면서 판단력을 길러보시면 좋을것 같습니다!

테스트 범위 설정에 대해서도 의견을 듣고 싶습니다.

요구사항을 구현할 때는 가능한 한 작은 단위부터 TDD를 시작하려고 했습니다.
예를 들어 loseBettingAmount()처럼 메서드 단위에서
"플레이어가 배팅 금액을 잃는다", "플레이어가 수익을 돌려받는다" 같은 규칙을 먼저 검증하는 방식입니다.

그런데 구현을 진행하다 보니,
결국 상위 객체에서 여러 도메인이 함께 협력하는 흐름을 테스트하게 되면서
단위 테스트라기보다 얇은 통합 테스트에 가까운 형태로 올라가게 되었습니다.

이런 흐름이 자연스러운건지 궁금합니다.
(BettingAmount를 만들고, 수익을 계산해야하니 CalculateProfit을 만들고, 어 그런데 한 명이 아니라 여러명이네?
그럼 BettingAmounts도 있어야겠네 해서 만들고....그러다보니 정작 테스트하는 건 CalculateProfit에서 하고...)

이 과정에서
작은 단위 테스트를 먼저 쌓고, 이후 협력 객체를 묶는 얇은 통합 테스트까지 가는 흐름이 자연스러운지 궁금합니다...
(특히 GameResultManagerTest가 그런식으로 구현되어 있습니다.)

특히 상위 테스트가 통과하면 하위의 여러 작은 메서드들도 간접적으로 함께 검증되는 느낌이 드는데,
이럴 때 작은 단위 테스트와 협력 테스트의 경계를 어떻게 잡는 것이 좋은지도 의견을 듣고 싶습니다.

뭔가 메서드 단위로 시작해야지! 하고 시작하는데 돌아보면 결국 기능단위 인 것 같아서 고민이네요....

작은 단위에서 테스트가 된것들은
상위 레벨에서는 과감하게 테스트 하지 않아도 된다고 생각합니다.

추가적으로요구사항이 메서드의 길이를 10줄 이하로 하라는것 때문에 개행없이 이렇게 처리하신걸까요??
가독성이 많이 떨어지는것 같습니다!
10줄이하는 가독성을 올리기 위해서인데 거기에 매몰되어 오히려 가독성을 해치는게 아닐지 고민해보면 좋을것 같습니다

또 테스트에서 중복이 많은 부분들을 어떻게 처리해 코드를 줄일수 있을지도 고민해보면 좋겠네요

불변객체는 setter메서드를 제공하지 않으며, 내부상태를 제공하는 메서드는 제공하지 않거나, 방어적복사를 통해 제공한다. 또한, 생성자를 통해 초기화 된 후 GC에 의해 소멸되기 전까지 값이 변하지 않는다. 예시로는 String이 있다. 한편, final 변수를 통해 불변객체를 달성할 수 있다고 착각하지만 아니다. final은 재할당이 안되지만, 값은 변한다. final로는 달성할 수 없는 불변객체를 일급 컬렉션과 래퍼 클래스(VO)를 통해 달성하게 해준다.

제가 이번에 불변객체를 도입하면서 공부해본 내용입니다. 제가 이해한 방향이 적절한지 먼저 확인받고 싶습니다.

또 한편으로는 이번에 불변 객체를 공부하고 적용해보면서, 좋은 설계라는 이유로 불변성 자체에 과하게 집착하게 될 수도 있겠다는 느낌이 들었습니다. (이전에 저는 아키텍처 패턴에 강하게 집착한적이 있어서 그 때와 비슷한 느낌이 들었던 것 같네요)

그래서 실제 현업에서는 불변 객체를 어느 정도까지 적용하는 것을 목표로 하는지, 그리고 "여기서는 불변으로 두는 것이 적절하다"와 "여기서는 실용적으로 가변을 허용해도 된다"를 어떤 기준으로 판단하는지 의견을 듣고 싶습니다.

불변객체는 사용할 수 있으면 사용하는게 좋을것 같아요
실무에서는 인스턴스의 필드가 최소 10개는 되는데 매번 객체를 새롭게 생성해서 반환하는건 현실적으로 어렵기 때문에 불변을 많이 사용하지는 않긴합니다.

이것도 단순 궁금증인데, 객체지향 생활체조에 따르면 인스턴스 필드를 3~4개로 유지하라고 하잖아요??
그러데 실무에서는 그럼에도 불구하고 10개정도로 유지가 되는 주된 이유가 무엇인가요??
현실과 코딩 사이에 항상 괴리가 발생하나요??

현실적으로 해당원칙을 지키려면 많은 클래스를 가져야하는데
그 클래스를 관리하고 이해하는것보다 하나의 클래스에서 처리하는게 더 이해하기 쉽고 간단한것 같아요

예시를 찾아보니 Company를 위 원칙으로 지키기위해서는 6개의 클래스가 별도로 필요하더라고요
DB에 저장될때 entity는 결국 하나일텐데 매핑해주는 과정도 쉽지않을것 같고요 그리고 이후 사용하겠지만 jpa를 사용하다면 도메인 = entity로 사용하는 경우도 많아서 쉽지 않을것 같습니다

// 3개 이상의 인스턴스 변수를 필드로 가지는 Company
public class Company{
    private Long id;
    private String name;
    private String tel;
    private String ceoName;
    private String address;
    private String addressDetail;
    private String zipcode;
}

// 2개 이하의 인스턴스 변수로 구성된 객체 간의 관계로 표현한 Company
public class Company{
    private Long id;
    private BaseInfo baseInfo;
}

public class BaseInfo {
    private String name;
    private AdditionalInfo additionalInfo;
}

public class AdditionalInfo {
    private Contact contact;
    private Location location;
}

public class Contact {
    private String tel;
    private String ceoName;
}

public class Location {
    private Address address;
    private String zipcode;
}

public class Address {
    private String main;
    private String detail;	
}

이 부분 체크해봐주세요!

LineFeed 오류가 있었던 것 같습니다!
반영했습니다!

돈과 관련된 타입이 int가 적절할지 고민해보면 좋을것 같습니다

1. 엄청 큰 돈이 들어올경우
2. 달러 등 소수점이 있는경우
3. 부동소수점 문제

위 세가지 문제에 대해 고민을 해보고 판단해보시면 좋을것 같습니다!

리뷰 주신 내용을 바탕으로 돈 타입과 계산 방식에 대해 다시 생각해봤습니다 🤔

1. 큰 금액 처리
   현재는 int를 사용하고 있어 정수 overflow 가능성이 있습니다.
   이 경우 배팅 금액의 상한을 도메인 규칙으로 두는 방향이 나을지,
   아니면 타입 자체를 long으로 변경해 표현 범위를 넓히는 방향이 더 적절할지 고민하고 있습니다.

2. 소수점이 있는 화폐
   현재는 원화 기준의 정수 금액만 가정하고 있지만,
   달러처럼 소수점 단위를 가지는 화폐까지 고려한다면 지금 구조는 한계가 있다고 느꼈습니다.
   그래서 과제 범위 안에서는 100원 단위처럼 입력 단위를 제한하는 도메인 규칙을 두는 방식도 가능하다고 생각했습니다.

3. 부동소수점 문제
   double/float는 소수를 2진수로 완전히 정확하게 표현하지 못해 계산 오차가 생길 수 있다는 점도 함께 고민하게 되었습니다.
   현재 1.5는 2진수로 표현이 가능하기에 오류가 드러나지는 않지만,
   돈 계산을 double 기반 상수에 의존하는 방식은 확장성이나 안정성 측면에서 아쉽다고 느꼈습니다.

그래서 현재는 PROFIT_RATE를 BigDecimal로 두고 계산 로직을 리팩터링하는 방향도 고려하고 있습니다.

이렇게 변경방향을 고려하고 있는데, 더 나은 방식이 있을까요???

돈과 관련된것들은 실무에서도 대부분 아니 100% BigDecimal 을 사용하고 있을거에요
더 나아가면 참고로 money라는 개념은 currency와 함께 항상 같이 다녀야하는 의미로 대부분 사용하고 있을거에요

public class Money {
    private final BigDecimal amount;
    private final String currency;
}

위와 같은 형태로 많은곳에서 쓰이고 있을텐데 참고해보시면 좋을것 같습니다.(여기서 currency까지 적용은 오버엔지니어링이라 생각합니다)
https://shopify.dev/docs/api/admin-graphql/latest/objects/MoneyV2
실제 shopify와 같은 글로벌 기업들이 어떤 타입으로 Money를 관리하고 있는지 참고하면 좋을것 같네요

상황에 따라 더 가독성, 성능 등을 잘 고려해서 판단하시는게 좋을것 같습니다!
모든 상황에서 스트림이 좋다고 forEach, for문이 좋다고 할수는 없을것 같아요
딱 정의해서 말할수 없는것 같고 개발을 진행하면서 판단력을 길러보시면 좋을것 같습니다!

이런 부분은 stream 이 좋을것 같아요!

반영했습니다!!

불필요한 메서드 아닐까요 생성자에서 생성하면 될것 같네요!

아하 그러네요!!!
감사합니다 👍

이것도 굳이 메서드 분리를 할필요가 있을지 고민해보면 좋을것 같습니다

저는 그래도 Dealer에게 초기 카드를 분배한다는 의도를 더 담고 싶어서 distributeCardToPlayers와 동일하게 한 번 더 감쌌던 건데, 굳이 안 그래도 의미가 잘 전달이 되나요?? 지금은 아래와 같이 리팩토링한 상태입니다!

    public void distributeInitialCards() {
        distributeInitialCards(dealer);
        distributeCardToPlayers(players);
    }

    private void distributeCardToPlayers(Players players) {
        players.forEach(this::distributeInitialCards);
    }

    private void distributeInitialCards(Participant participant) {
        drawCardTo(participant);
        drawCardTo(participant);
    }

불변객체는 사용할 수 있으면 사용하는게 좋을것 같아요
실무에서는 인스턴스의 필드가 최소 10개는 되는데 매번 객체를 새롭게 생성해서 반환하는건 현실적으로 어렵기 때문에 불변을 많이 사용하지는 않긴합니다.

"-" 를 이렇게 붙이는 방식은 가독성도 떨어지고 의미전달을 놓치기 쉬운 코드인것 같아요
-1을 곱하거나 java.Math의 메서드등을 활용하여 좀더 가독성 좋은 방향을 고민해보면 좋을것 같습니다!

아하, 그렇군요!
처음에는 딜러의 수익이 참가자들 수익 총합의 반대 부호라 단순히 -를 붙이는 게 직관적일 것이라고 생각했었습니다.

하지만 리뷰어님 말씀대로 긴 스트림 체이닝 앞에 단항 연산자가 있으니 시각적으로 놓치기 쉽고,
다른 사람이 읽을 때 가독성이 떨어질 수 있다는 점도 공감이 가네요

조언해주신 방향을 바탕으로 플레이어들의 총 수익을 구하는 부분을 변수로 먼저 분리하고, Math.negateExact() 를 사용하여 '수익을 반전시킨다'는 의도가 코드에 더 명확히 드러나도록 수정했습니다. 좋은 피드백 감사합니다! 👍
(해당 메서드가 정수 오버플로우도 예외처리해주는군요? 배워갑니다 ㅎㅎ)

ParticipantCards, Deck 각각이 List 를 필드로 가진 일급컬렉션 각각 클래스가 되어야할것 같습니다.
Cards라는 클래스는 현재 구조에서 필요없을것 같아요
객체 클래스의 depth만 깊어져서 오히려 복잡성이 증가하고 있는 구조인것 같습니다

에이스 점수 계산을 위해서 changeAvailableAceAcount가 있는구조가 좋은 방향인지도 고민해보면 좋을것 같아요
점수 계산을 할때 ace 여부를 체크하면 되지 않을까요?

이 부분은 사이클2의 핵심 요구사항인것 같은데 현재 구현이 안되어있는걸까요?

구현되어 있었는데 제가 깜빡하고 주석을 제거 안했네요 ㅜㅜ
그냥 단순 궁금증인데 예를 들어 추후 구현 혹은 리팩터링 사항이다. 이런 내용도 프로덕션 코드에서는 주석을 안남겨 놓나요??
뭔가 제가 생각했을 땐 코드에 대한 설명이나 의도를 주석으로 남겨도 괜찮지 않을까 생각하는데, 오히려 주석없이 메서드명만으로 정확한 의도를 전달할 수 있어야 한다고 들어서요.
하지만 같은 메서드라도 사람마다 생각하는 게 다르니, 주석으로 저맥락 설명을 적어놓는 게 협업하는 게 낫지 않을까..라는 주관적인 생각입니다..

코드를 보고 이해하기 어렵거나 쉽게 알기 어려운 부분에 대해서는 주석을 남겨놓습니다.
하지만 여기에서의 로직이 코드상으로 이해하기 어렵거나 한 부분은 없을것 같아요. 특이한 로직이 있는것도 아니고요!

주석은 코드가 변경되어도 같이 변경하는걸 까먹기 쉽기 때문에 웬만하면 작성하지 않는 방향으로 가는게 옳은 방향일것 같습니다.

현실적으로 해당원칙을 지키려면 많은 클래스를 가져야하는데
그 클래스를 관리하고 이해하는것보다 하나의 클래스에서 처리하는게 더 이해하기 쉽고 간단한것 같아요

예시를 찾아보니 Company를 위 원칙으로 지키기위해서는 6개의 클래스가 별도로 필요하더라고요
DB에 저장될때 entity는 결국 하나일텐데 매핑해주는 과정도 쉽지않을것 같고요 그리고 이후 사용하겠지만 jpa를 사용하다면 도메인 = entity로 사용하는 경우도 많아서 쉽지 않을것 같습니다

// 3개 이상의 인스턴스 변수를 필드로 가지는 Company
public class Company{
    private Long id;
    private String name;
    private String tel;
    private String ceoName;
    private String address;
    private String addressDetail;
    private String zipcode;
}

// 2개 이하의 인스턴스 변수로 구성된 객체 간의 관계로 표현한 Company
public class Company{
    private Long id;
    private BaseInfo baseInfo;
}

public class BaseInfo {
    private String name;
    private AdditionalInfo additionalInfo;
}

public class AdditionalInfo {
    private Contact contact;
    private Location location;
}

public class Contact {
    private String tel;
    private String ceoName;
}

public class Location {
    private Address address;
    private String zipcode;
}

public class Address {
    private String main;
    private String detail;	
}

돈과 관련된것들은 실무에서도 대부분 아니 100% BigDecimal 을 사용하고 있을거에요
더 나아가면 참고로 money라는 개념은 currency와 함께 항상 같이 다녀야하는 의미로 대부분 사용하고 있을거에요

public class Money {
    private final BigDecimal amount;
    private final String currency;
}

위와 같은 형태로 많은곳에서 쓰이고 있을텐데 참고해보시면 좋을것 같습니다.(여기서 currency까지 적용은 오버엔지니어링이라 생각합니다)
https://shopify.dev/docs/api/admin-graphql/latest/objects/MoneyV2
실제 shopify와 같은 글로벌 기업들이 어떤 타입으로 Money를 관리하고 있는지 참고하면 좋을것 같네요

Cards 라는 클래스에서 추후 공통로직으로 쓰일만한게 어떤게 있나요??
제가 생각했을때 지금 Cards 의 메서드들은 공통적인 기능이라기보다 List 에서 기본적으로 제공되는 기능들을 한번더 호출하는 역할 밖에 없는것 같아요
추후 공통적인 기능이 생긴다는 영역도 List 에서 제공되는걸 한번더 메서드 depth만 늘릴것 같다고 생각합니다!